1. Avant-propos

1.1. About Papyrus

  • eclipse-based editor for UML

    • Complete UML 2.5 specificiation support

    • SysML™ 1.2, MARTE 1.1, …​

  • Tool for defining UML-based DSLs

    • UML profiles

    • Support for customizability

    • Open, robust, highly scalable

    • Model-Driven Egineered (written using Papyrus itself)

  • More details:

    PapyrusLogo256x256
    Figure 1. https://www.eclipse.org/papyrus/

1.2. About the modelers

People from CEA-List involved in this case study (special thanks):

Project involvment (3.5 days):

  • metamodel + profil ⇒ 1d

  • customization ⇒ 2d

  • example farming model ⇒ 0.5d

Process:

  • confcall with client

  • documents and screen capture

  • synchro/discussions with Benoit

  • use of common repo (github)

2. Profile-based approach

Contribution by Saâdia Dhouib, Florian Noyrit, Jean-Michel Bruel.

2.1. What is a profile ?

  • Abstract syntax for a new language

    • Set of stereotypes

    • Set of OCL constraints

profile JT

2.2. General process

The idea behing this approach is that there will be some benefits in the use of the UML standard. Hence the DSL will be based on UML by using the profile mechanisms.

profil BS
Figure 2. A profil based approach (taken from [Tatibouet14] and inspired by [Selic07])

As illustrated in this figure, here is the processus we can follow:

Step #1

Starting from the expected DSL (most of the time a modelsc or a graphical représentation) and a description of the domain model (modelmde)

input
Figure 3. Inputs: description of the domain model
Step #2

A domain modelmde is more precisely defined (e.g. a class diagram such as Main concepts of the domain model)

step1
Figure 4. From modelsc to modelmde
image001
Figure 5. Main concepts of the domain model
image002
Figure 6. Concepts of the domain model linked to activities
Step #3

The concepts (e.g., Farm in Main concepts of the domain model) are mapped to the more suitable UML elements (e.g., Class in Mapping concepts with UML metamodel to define a profile)

step2
Figure 7. Mapping domain concepts to UML metamodel
image003
Figure 8. Mapping concepts with UML metamodel to define a profile
Step #4

If the concepts directly match UML concepts (or if there is a way to slightly modify them so that they match) then it is possible to define a profile. (see e.g., Mapping concepts with UML metamodel to define a profile)

Step #5

Else another solution (e.g., defining a metamodel from scratch) should be studied.

Step #6

It is time then to "customize" the DSML to make it as close as possible as the user domain representation.

dsml
Figure 9. Customizin the DSML
image004
Figure 10. Improving the profile
Note

There are different ways of defining the domain model:

  • the domain expert provides the domain model (e.g., UML class diagram)

  • the UML expert translate the concepts from the stakeholders into a domain model

  • the UML expert and the domain expert build a modelmde as close as possible of the expected DSL and the UML expert extract the core concepts in a domain model

2.3. Iterative process

The above process is iterative. The constructs are introduced by step. The profile is experimented in a modelsc importing the profile so that the user can validate that the concepts are captured adequatly. This is were the UML expert can use tuning possibilities.

2.4. Improvements

The next steps can consist in:

  • defining a dedicated diagram

  • providing a wizard for the new language

  • defining a specific property view (File ▸ New …​ Property View Configuration and then right click on the generated property)

  • Working on the concrete syntax:

    • customizing the styles (look & feel)

    • customizing New ▸ Child

    • customizing the Model explorer

    • packaging together the profile, the property view, the palette, etc.

Tip

  • Papyrus provides a DSML Configuration plugin to help on these steps.

  • There is also the possibility of defining a Feature that group together a set of profiles

    wizard

2.5. Example of work on the concrete syntax

Let us illustrate the need for a specific concrete syntax.

2.5.1. Structural Domain Model

FarmingDomainModelStucture

2.5.2. Functional Domain Model

FarmingDomainModelFunctional

2.5.3. Structural profile

FarmingProfileStructure

2.5.4. Functional profile

FarmingProfileFunctional

2.5.5. Using the profile: Farm structure

FarmStructure

2.5.6. Using the profile: Papyrus context

ModelingInterface

2.5.7. Crop Workshops description

CropWS

2.5.8. Activity description (UML Activity Diagram)

CornActivity

2.5.9. Activity description (UML Activity Diagram)

WheatActivity

2.5.10. Customizing the Model Explorer

ModelingInterfaceZoomModelExplorer

2.5.11. Customizing the Palette (structure)

ModelingInterfaceZoomPalette1

2.5.12. Customizing the Palette (activities)

ModelingInterfaceZoomPalette2

2.5.13. Customizing the Palette (property view, structural element)

ModelingInterfaceZoomPropertiesView1

2.5.14. Customizing the Palette (property view activity element)

ModelingInterfaceZoomPropertiesView3

2.5.15. Animation and external tools coupling

moka1
moka2
moka3

2.6. Conclusion

2.6.1. Profile definition

  • in terms of stereotypes (extending metaclasses)

  • adding specific properties to the stereotype (e.g., period in this figure)

  • adding OCL constraints

2.6.2. Main differences

  • Using ecore

    • the process consists in starting from scratch, from an empty metamodel

    • the domain model is then define by construction

  • In the UML profile approach

    • we start with an existing (complete) metamodel

    • and the profiling activity consist in restricting it to specific elements

    • the assumption is that their is a benefit in having both additional concepts and tooling, notably in terms of

      • extensibility mecanisms

      • scalability

2.6.3. (honest) Feedbacks

  • Easy tuning and customizing possibilities

  • Almost like doing regular UML modeling

  • UML good knowledge required

  • Not trivial

  • Great work from CEA (3.5 days of work)

  • Need close loop with the client (agile manifesto)

2.6.4. DSML from scratch: the "Wysiwyg approach"

word
Figure 11. Free and easy to edit from scratch

  • No constraint on what we type

  • Immediate visualization of the result

  • Possibility to have templates

  • More and mode styles and quality

2.6.5. DSML as UML profiles: the "LaTeX approach"

dsl
Figure 12. Formal and constrained typing

  • Constrained language

  • No immediate visualisation of the result

  • Naturally based on templates

  • Rich in libraries and styles

  • Possibilities to see what you get on (almost) real-time

  • Collaborative and user-friendliness improvements

2.6.6. Converging

  • DSML vs Profile-based ⇒ wrong approach

  • DSML or Profile-based ⇒ good question

  • Both Sirius and Papyrus part of Polarsys!

polarsys logo

About…​

Document réalisé par Jean-Michel Bruel via Asciidoctor (version 1.5.1) de 'Dan Allen', lui même basé sur AsciiDoc. Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

Photo credits: